Received: 13 August 2019 Revised: 28 November 2019 Accepted: 23 December 2019 ® 


Check for 
DOI: 10.1002/nem.2093 updates 


SPECIAL ISSUE PAPER WILEY 


Weighted voting on the blockchain: Improving consensus in 
proof of stake protocols 


Stefanos Leonardos!?® | Daniël Reijsbergen'® | Georgios Piliouras!” 


liTrust Centre for Research in Cyber 
Security, Singapore University of Summary 


Technology and Design, Singapore Proof of stake (PoS) protocols rely on voting mechanisms to reach consensus on 


?Engineering Systems & Design, 


; eee the current state. If an enhanced majority of staking nodes, also called valida- 
Singapore University of Technology and 


Design, Singapore tors, agree on a proposed block, then this block is appended to the blockchain. 
Yet these protocols remain vulnerable to faults caused by validators who abstain 
Correspondence : P a A 2 a 
ee a ee ee either accidentally or maliciously. To protect against such faults while retaining 
Research in Cyber Security, Singapore the PoS selection and reward allocation schemes, we study weighted voting in 


University of Technology and Design, 8 
Somapah RD, 487372, Singapore. 
Email: stefanos_leonardos@sutd.edu.sg 


validator committees. We formalize the block creation process and introduce val- 
idators' voting profiles which we update by a multiplicative weights algorithm rel- 
ative to validators’ voting behavior and aggregate blockchain rewards. Using this 


Funding information A ae . ae : 
National Research Foundation (NRF), framework, we leverage weighted majority voting rules that optimize collective 
Grant/Award Number: NRF-NRFF2018-07 decision making to show, both numerically and analytically, that the consensus 


and NRF2016NCR-NCR002-028; MOE 


AcRF Tier 2, Grant/Award Number: ie de CAs ; . i í 
2016-T2-1-170; SUTD, Grant/Award potential issues and limitations of weighted voting in trustless, decentralized 


mechanism is more robust if validators’ votes are appropriately scaled. We raise 


Number: SRG ESD 2015 097 networks and relate our results to the design of current PoS protocols. 


1 | INTRODUCTION 


In the Nakamoto consensus protocol! that underpins the popular Bitcoin cryptocurrency, a single miner claims the right 
to append the next block to the blockchain by a demonstrating so-called proof of work (PoW), ie, the solution to a mod- 
erately hard cryptographic puzzle. The strengths and vulnerabilities of this mechanism are well understood; see previous 
studies.*” Two fundamental properties satisfied by PoW selection are the following: (i) Miners holding p% of computa- 
tional power will create on average p% of blocks that will be part of the blockchain assuming that all miners follow the 
protocol. This property relies on the randomness of the cryptographic puzzle and ensures fairness in the allocation of 
mining rewards.*° (ii) Miners can be selected as the next block creators only when they actually create and submit the 
block to the network. This property asserts that the random selection of the next block creator and the creation of the next 
block occur simultaneously. 

Proof of stake (PoS) or virtual mining protocols!” constitute alternative selection mechanisms that aim to retain PoW's 
benefits while improving on its weaknesses.!"* While different PoS protocols propose different schemes,'*"* in general, 
the block proposal mechanism is the following: blocks are created by staking nodes, also called validators,!°”° who are 
granted the right to participate in the block creation process by locking capital in protocol currency, called stake. Subse- 
quently, a pseudorandom mechanism selects nodes proportionally to their stake to form committees that will decide on 
the validity of a block proposed by a selected node, called block proposer or leader. At the core of the consensus mechanism, 


A preliminary version of this paper appeared in IEEE International Conference on Blockchain and Cryptocurrency (ICBC 2019) and awarded with the 
Best Paper Award. The additional contributions of this version are detailed in Section 1.2. 
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the selected validators cast approval or disapproval votes on the proposed block. If an enhanced majority of approval votes, 
usually 2/3 of the committee size,”! is reached, then the proposed block is accepted and appended to the blockchain. 

However, maliciously or accidentally abstaining validators can cause consensus failures and stall the blockchain.* The 
reason is, that unlike Nakamoto consensus,”” PoS protocols decouple the selection of block creator(s) from the actual 
block creation and hence do not satisfy property (ii) above. Since consensus on the “valid” state of the blockchain relies 
on the voting behavior of all participating validators, this also implies that the actual rate of blocks that a validator gets to 
create may differ from the times that she gets selected in a committee. Hence, while the PoS selection mechanism aims 
to ensure fair allocation of “mining” rewards in line with PoW's property (i) above, in practice, it may fail to do so. These 
observations motivate the following question: 


How can we improve the efficiency and robustness of the consensus mechanism, ie, how can we use informa- 
tion on validators’ past voting patterns to enforce that with overwhelming probability the selected validator 
committees will reach consensus on the “valid” state of the blockchain? 


The problem of improving consensus has been treated in the context of fixed-size committee voting by a rich stream of 
literature.?*?” The derived solutions depend on quantifying voters’ abilities to make correct decisions and apply weighted 
voting rules in which votes are weighted according to voters’ profiles. Our goal is to apply these results in the setting of 
PoS protocols. The link is immediate, since, as remarked in Ben-Yashar and Nitzan,” the assumptions of their original 
model imply both decentralized information processing and limited communication. The additional challenges that have 
to be treated in the blockchain context concern the updating of these profiles and protection against their manipulation 
by adversaries. 

To address this problem, we formulate the proper mathematical framework and develop a model to quantify validators’ 
voting profiles. The proposed scheme is applied once voting committees have formed and does not modify the underlying 
PoS selection and reward mechanisms. Each staking node (validator) is assigned a score based on her so-far contribution 
to protocol execution. When selected for a committee, her vote is weighted relative to her profile, and consensus is decided 
according to a weighted majority rule that maximizes the expected collective rewards.”*° Finally, based on her vote and the 
overall consensus outcome, her voting profile is revised according to a fully parametrizable multiplicative weights update 
(MWU) algorithm.”*° Supported by numerical examples and simulations, our findings demonstrate that weighted voting 
renders the consensus mechanism more efficient, even if more than 1/3 of nodes are not properly voting. In this way, the 
proposed scheme restores fairness without compromising other PoS features. Additionally, since it does not modify the 
underlying PoS mechanism, it can be tested, implemented, and reverted with minimal cost to existing protocol users. 

We raise issues that pertain to weighted voting such as loss of anonymity and centralization and discuss their relevance 
to protocol design and implementation. 


1.1 | Related work 


Although weighted voting in distributed systems is known to increase efficiency, incentive compatibility,*°*! and network 
reliability,*? it also raises additional risks.***° Similar to proof of reputation systems,*° weighted voting deviates from the 
principle one node-one vote and hence is vulnerable to manipulation by adversaries. Weighted voting becomes particularly 
relevant in less anonymous,”” private, or permissioned blockchains,**“° in delegated PoS (DPOS) protocols*!? and in PoS 
protocols with low targeted number of staking pools.** However, under rather general assumptions, it can also be relevant 
for permissionless PoS or hybrid PoW and PoS systems.!*!° We provide such a use case in Section 5.1. 

A profiling system reduces or eliminates the anonymity of staking nodes which is at odds with the design philosophy of 
permissionless blockchains. However, with blockchain governance yet to be determined, introducing less anonymity may 
be a desired feature. Recent results support relatively low desired numbers of staking nodes“ or stake pools.‘ In such 
schemes, reputation will implicitly or explicitly influence protocol execution. Moreover, stake pools can retain anonymity 
at the user level, ie, while the pool itself becomes identifiable by its voting profile, the users remain anonymous. In any 
case, the introduction of voting profiles and weighted voting seems particularly relevant to permissioned blockchains or 
DPOS mechanisms. 

More interesting is the implementation of the weighted voting algorithm in conjunction with state-of-the-art consen- 
sus schemes such as the DPOS of EOS.IO.“ Instead of substituting the underlying consensus mechanism, the weighted 


*Malicious absention refers to nonvoting or incorrect voting to attack the protocol, whereas accidental abstention refers to a variety of reasons, such as 
dropping offline, experiencing network latency, bugs in client updates, or being a victim of a censoring/eclipse attack. 
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voting scheme enhances its functionality and operability by providing an additional layer of defense against accidental 
or adversarial system failures. In fact, in consensus systems that use a limited number of delegates, weighted voting can 
prove beneficial in accelerating consensus and enhancing their scalability, liveness, and safety. This rests on the fact that 
assigning and updating profiles to the delegates is much easier than in general permissionless blockchains. However, even 
in the latter case, the expected latency (and overhead) that will be introduced to the system by the profiling system does 
not exceed nor significantly increases the computational complexity of updating the validators’ stakes. 

Finally, claiming that all PoS protocols fit under the stylized model—see Section 2—that we use to design the proposed 
weighted voting scheme would be an oversimplification and wrong. Yet most PoS protocols that we are aware of involve 
voting mechanisms and hence may benefit—to a larger or lesser extent—from the present proposal. An incomplete list 
includes previous studies.1315-18 For more extensive details of PoS protocols, we refer to previous studies. 124547 Further 
comparisons to existing proposals and implementation details are given in Section 6. 


1.2 | Outline 


In Section 2, we abstract the PoS consensus mechanism as a voting game. In Section 3, we construct the improved voting 
scheme and illustrate it with examples. Section 4 is devoted to the design of the updating algorithm and the derivation 
of bounds on the validators’ faulty behavior that can be tolerated with significantly affecting their profiles. The resulting 
scheme—weighted voting rule and multiplicative weight updating algorithm—are tested and related in potential use 
cases in Section 5. We conclude the paper with a discussion about limitations and implementation issues in Section 6 and 
a summary of our findings in Section 7. 

As an extension of a conference paper,* the present article contributes both technical- and application-specific mate- 
rials that make the paper self-contained and enhance the intuition behind the derived results. In addition to a detailed 
comparison with related work, cf Section 1.1, technical extensions comprise Lemma 1 and its proof, the proof of Theorem 
1, Figure 1, and Remark 1. From an application-oriented perspective, the present paper elaborates on the design and 
optimal parametrization of such voting schemes in practice. This is done in Sections 4.1, 5.1, and 5.2 in the context of 
the state-of-the-art PoS proposals and implementations, such as Ethereum with Casper Friendly Finality Gadget (FFG) 
and EOS.IO. The main focus of the analysis is in the mechanics of committee formation and the risk mitigation that is 
achieved via the proposed scheme for potential investors. In particular, the new content addresses incentives and adver- 
sarial behavior in potential use cases and moves forward to explain the steps for the adoption of the proposed scheme in 
practice. 


2 | THE MODEL 


Our terminology is based on the Ethereum 2.0 PoS protocol specification.!* Yet our model remains as general as possible 
in an effort to capture similar voting mechanisms implemented by related PoS platforms. 


Time: Time is divided into time slots t € {0,1,2, ... } of fixed duration d. Each time slot is dedicated to the proposal 
and creation of a new block B;. Time slot t = 0 is the time of creation of the genesis block Bo. 

Validators: The main actors in the block proposal and creation mechanism are the staking nodes, also called validators, 
denoted by i € I, where I C N is the set of all validators. /3;, will denote the set of blocks for which validator i is aware 
of at time t > 0. 

Stake: The deposit or stake is the amount of the underlying cryptocurrency that a potential validator locks as PoS to 
participate in the block creation process. Such deposits may change over time. Accordingly, let vi; > 0 denote the stake 
of validator i € I and v; := ieit the total stake at time slot t € N. If vj, > 0, then validator i is called active at time 
slot t. Validators who have withdrawn from I or who have not entered it yet can be thought of as validators with stake 
viz = 0. Thus, although the set of validators is dynamic, we may write I instead of I; to denote the set of validators at 
any time t > 0. 

Block proposer and committees: To create blocks and extend the blockchain, active validators are selected proportion- 
ally to their stake by a pseudorandom mechanism that assigns to each time slot t a leader or block proposer and a 
fixed-sized committee N, = {1,2, ... ,n} of validators.’ The block proposer is assigned the task to propose a block B, 


*The mechanics of the pseudorandom mechanism vary between different protocols. Here, we are not interested in risks associated with manipulating 
this mechanism and focus on the mechanics of the voting process once a random committee has been formed. 
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to the committee. In turn, the committee votes on whether the proposed block should be appended to the blockchain 
or not. This process constitutes the core of the consensus mechanism and will be the focus of the present paper. 
Validators’ strategies: The set of strategies of a validator who has been selected in a committee will be denoted by 
S = {-1,1}, where —1 stands for rejecting and 1 for approving the proposed block. In particular, —1 also corresponds 
to not casting a vote, either deliberately or accidentally. Accordingly, let Xi; denote the indicator random variable 


X= 1, ifvalidator i voted on the approval of the proposed block B, intimeslot t 
it — \ —1, otherwise. 


We will write KX; := (Xit Xt ... Xn.) to denote the random vector of all indicator random variables prior to the 
validators’ voting decisions and x; := (X14,X24, ... Xn, t) E {-1, 1}” to denote the realized decision or action profile of 
the committee at time t > 0. Accordingly, we will write X := {—1, 1}” to denote the set of all possible decision profiles. 
Decision rule: A decision rule f : X > {-1,1}, also called social choice function or aggregation of preferences rule, 
is a function that receives as input the action profile x, and outputs a decision in {—1,1}, where —1 and 1 stand for 
disapproval and approval of the proposed block, respectively. We will focus on (simple or enhanced) majority rules 
fa q € (0.5, 1] defined by 


n 
j bo ak — 
fat) = 4b 1 Èu 2 Cq- Dn, (1) 
—1, otherwise. 


If at least a fraction q € [0.5, 1] of the selected validators approve the proposed block, then this block is appended to 
the blockchain. Otherwise, the time slot remains empty and the mechanism progresses to the next time slot. 


If block proposers follow the protocol and do not behave maliciously, then all proposed blocks are valid. Moreover, if 
the network is not partitioned and network latency is insignificant (lower than the time slot duration during which votes 
are expected to appear), then there is no controversy about which blocks are valid, since all validators view essentially the 
same blockchain (state), ie, Bi; := B for alli € I, t > 0. Under these conditions, the required majority should be reached 
and valid blocks should be regularly approved and appended.!>!8 However, in practice, two main reasons may lead to 
failures on the consensus mechanism. 


e Adversarial behavior: a malicious node abstains from voting or censors other validators’ votes to block the required 
majority and stall the block creation process. 

Accidental behavior: validators drop offline accidentally or due to negligence, they experience bugs on client updates 
or bad network connectivity, their votes do not propagate through the network in the expected time slot, or they are 
victims themselves of a censoring/eclipse attack. 


Our goal is to study how existing results on optimizing aggregation of preferences in committees, in particular the results 
of Ben-Yashar and Nitzan,” Nitzan and Paroush,* and Shapley and Grofman?® can be applied to the PoS blockchain 
setting and improve the underlying consensus mechanism. The application of these results will be immediate once we 
have defined the proper framework. 


3 | ANIMPROVED VOTING RULE 


To optimize the consensus process from an aggregative perspective, we quantify the collective benefits and losses (payoffs) 
from correct and wrong decisions, respectively. This is done in Table 1. 

The benefit from making a correct decision, ie, approving a valid block or rejecting an invalid block, is scaled to 1. Here, 
—1 denotes an invalid and 1 a valid block B,, cf Section 6. Ifa valid block is rejected, then a loss of 7, > 0 is incurred, which 
corresponds to the waste of computational resources and the failure of the system to process pending transactions. On the 


TABLE1 Collective welfare from consensus outcome Proposed Block B, 
Valid (1) Invalid (—1) 
Committee Approve 1 C4 


Reject —¢, 1 
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other hand, if validators vote for an invalid block, then 7, > 0 represents the losses from validating a conflicting history.* 
Determining the exact values of 7, and @, is a matter of protocol parametrization. In the present treatment, and without 
compromising the generality of the results, we will assume that ?, « la, ie, that accepting invalid blocks has greater 
repercussions for the system, since such blocks typically stem from malicious—and not accidental—behavior. Finally, let 
a E (0,1) denote the prior probability that a proposed block is invalid, eg, blocks that an adversarial is trying to create. 

Given the above, we seek to maximize the expected collective welfare E, at time slot t > 0. E; depends on the probabilities 
of accepting a valid block and of rejecting an invalid block under the decision rule f,, 


m (fq) = P (fa Xd = 11B: = 1), 
and z1 (fq) := P (fq X) = -1|B; = —1), respectively. Using this notation, 
E(f) =Q- AA+ l)n (fq) +a + la) n (fa), (2) 


where we have omitted constant terms. To estimate 71 ( fa) and mı ( fa): and hence, to maximize E;, we need to reason 
about the decision rule f4 and particularly about the distribution of the decision variables X; +. Fortunately, this can be 
done by retrieving existing information about validators’ past votes that have been stored as messages on the blockchain. 
This is captured by the notion of validators’ voting profiles that we introduce next. 


Voting profiles: Each validator i € I is assigned a score pis € [0,1] that corresponds to their voting profile at the start of 
time slot t. The value p;; can be thought of as validator i's decision ability or probability that i will vote correctly, ie, 


Pit := P (Xi = 1[B) = 1) = P(X, = -1|B, = -1), (3) 


for i € I,t > 0. For instance, in its simplest form, p;; can be thought of as the fraction of validators i's correct votes to 
the number of slots in {0,1, ... ,t — 1} that i was selected in a committee. In what follows, we will examine a more 
elaborate scheme to define the profiles p;; that depends on the collective welfare of the consensus outcome, cf Table 1. 
Initializing and suspending profiles: We will set a newly entering validator i's voting profile at pig := 0.5 and will require 
that pi; € [0.5, 1), for any t > g, where g > 1 denotes an initial grace period. If pj; < 0.5, for some t > g, then validator 
i will be suspended from I. The reasoning behind these choices is detailed in Section 6. 
Updating scheme: In general, an updating scheme is given by a function h : [0,1] x {-1,1} — [0,1] which revises 
validator i's voting profile after time slot t based on i's prior voting profile p; +, the correctness of her voting decision xis, 
and the current state 5,, ie, 

Pit+ı = h (Pis Xi,t> B:) > 
for t > 0. The current state B; may include all relevant information, such as the collective welfare parameters, cf 
Table 1, the validity of the proposed block and the consensus outcome. If a validator i € I has not been selected for 
slot t, then simply pitii1 = pis. A concrete updating scheme that fits in this description is developed in Section 3. 


Given the introduced validators’ voting profiles, we now return to the problem of maximizing the collective welfare Ez. 
Lemma 1. For a selected validator committee N = {1,2, ... ,n} at time slot t, we may condition on the vector of val- 


idators' voting profiles P; = (P11, P21» --- , Pnt) and write the probability x, ( fq\p:) of approving a correct block with the 
decision rule f as 


m(fap.)= >, (0 pu [I a-p) (4) 
x: fq(X)=1 i:x,,=1 JX, .=-1 

and similarly for z_, ( falp:). 

Proof. This expression for 71 ( falPr) is derived as follows: The summation ranges over all action profiles x, for which 


the decision rule f, approves the proposed block, ie, f, (x;) = 1. The double product inside the parenthesis is precisely 
the likelihood of each of these profiles given that validators’ decisions are independent. Specifically, the first product 


*This may include approval votes for a block that a malicious node is trying to create in order to double-spend or perform some other kind of attack. It 
may also involve votes that get wasted on blocks that will be subsequently reverted or abandonded. 
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ranges over all validators i € I who vote correctly, ie, i : xi, = 1, and multiplies each one's probability of a correct 
vote, ie, pis, and the second ranges over the remaining validators j € I who vote incorrectly, ie, j : xj; = —1, and 
multiplies each one's probability of voting incorrectly, ie, (1 — pj). 


Given these expressions, the problem of maximizing E, ( fa) can now be studied as an instant of the committee-voting 
models in Ben-Yashar and Nitzan,” Nitzan and Paroush,” and Shapley and Grofman.”° 


Example 1 (Adjusted from Shapley and Grofman”°). Consider a committee of five validators with voting profiles, ie, 
empirical probabilities of voting correctly, p = (0.9, 0.9, 0.6, 0.6, 0.6), as in Shapley and Grofman.”° In the unweighted 
case, or equivalently in the case in which all votes are weighted equally, and under the 2/3-majority decision rule f2/3 
that is commonly used in consensus protocols,”? the probability of reaching consensus on the correct block is equal 
to the probability that at least four out of the five validators vote correctly. This is 


0.970.6° + 2 - 0.67 (0.9) (0.1) + 3 - 0.970.67 (0.4) = 0.56, 


which is lower even than the lowest voting profile of 0.6. A naive improvement would be to only consider the vote 
of the validator with the highest voting profile, ie, of either the first or the second validator. This would increase the 
probability of correct voting to 0.9, however, at a toll on decentralization. 


In the naive improvement of the previous example, the vote of the best validator received a weight of 1 and the vote of 
all others a weight of 0. This raises the question of whether we can assign nontrivial weights (scale factors) to all validators 
and still improve the probability of a correct decision. The answer is affirmative and hinges on the notions of weighted 
voting and weighted majority rules. 


Weighted majority rule: For a set of n validators, let w, := (wit Was srs Wn) denote a vector of nonnegative 
weights or scaling factors, with w; := È; Wis. The weighted majority rule, fa (w), or simply fq, is defined as 


n 
1, if WitXit > (2q — 1) ws, 
fq (Kt) := È iis 2 (2q pws (5) 
—1, otherwise, 


for q € [0.5, 1]. If all votes are equally weighted, ie, ifw;, = 1 for all i = 1, ... ,n,t > 0, then (5) reduces to (1). 


Using this notation, our goal is to determine the weights w, and the weighted majority rule fz —or equivalently the 
quota q,—that optimize the collective welfare E, given the selected committee N, of validators at time slot t, ie, 


max {Er (fq, Wr) } - (6) 


This is the statement of the following theorem, which is due to Ben-Yashar and Nitzan” and in special instances due 
to Nitzan and Paroush™ and Shapley and Grofman.”° 


Theorem 1 (Optimal weighted voting scheme”). Consider a committee N, =  ({1,2,...,n} of valida- 
tors with voting profiles pp = (Dit, Pot, --- > Pn) that have been selected to vote on the proposed block 
in time slot t > 0. Then, given a and the collective welfare parameters a,r in Table 1, the deci- 
sion rule that maximizes the collective welfare, cf (6), is given by the weighted majority rule fz, with quota 


ai= 3 fi- (m (H2) +n (242) ) wr] (7) 


wus = In ( Pis ). fori=1,2,... ,n. (8) 


and individual weights 
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Proof. To solve (6), we will control the decision rule f, in (2). Then, the optimal quota and individual weights in (7) 
and (8) will follow naturally. To see this, we expand (2) using (4), which gives 


E, (fa) =(1-a) (l +/,) m (fa) +a + la) T (fa) 


aQ-aa+e) > (Tp I] (py) teatea > (1 pu [I o-Ps) 


x: f (x)=1 G1 JX) = X,3fq(%,)=-1 i:x,,=—-1 j:xXj=1 


5 (a-oa+en TT pu II ~pn)) 4 ¥ (zaseo T I pu [J G- -r1)) 


x: fq(%,)=1 ix) =l j:xj=-1 X: fq(%)=-1 j:Xj=l 


where we used that p; , denotes the probability ofa correct decision, cf (3). Our control variable to optimize the expected 
collective welfare in the previous equation is the decision rule f4. It is immediate, that a general decision rule f which 
maximizes E; is given by the following condition: for each decision profile x, E€ X = {—1,1}" append every block for 


which 
a-a)a+¢,) [| pie [| pi) > aata II Pit IT ( (1- pj) (9) 


i:x,,=1 JX, .=-1 i:x,,=-1 jix 
and reject it otherwise. The rule compares the contribution of the decision profile x, to the expected collective welfare 
if it is accepted (left-hand side) to its contribution if it is rejected (right-hand side) and returns the outcome that yields 
the maximum contribution. This establishes its optimality. It remains to translate this rule into a form decision rule 
in the form of (5) from which we will be able to deduct the optimal quota and weights. By grouping similar terms, we 


can rewrite (9) as 


l-a. 1+7, Pit S Pit 


a 1+@q i:x,=1 (1 — Pis) PU (1 — Pjs) ? 
and by taking the natural logarithm 


1+2 ; ; 
in (+ 2) +m ( t e)a >, m ( Pe )> » in ( 72- ). 
1+%q i:x,,=1 1— Pis jel 1—Djt 
where we used that the function In is monotone increasing. To proceed, we will use the transformations y; := 


(xi + 1) /2, so that 
Ka T, if x; = 1, 
i=) 0, if x= -1, 


1, if Xi = —-1, 
a= 4 0, ifx=1. 
Using this notation, we may rewrite the last inequality as 


l-a 1+? k Dit Dit 
l ( +1 r+ 1 t \g, 
n(5*) +(e) + fn (ghz) sins) 


Now, since y; — Zi = Xi, we obtain that 
ym Pis x> —In(=—*) -1n TE (10) 
1- — Pit a 1 + Ca 


). This establishes (8). To obtain (7), it 


remains to bring the right-hand side of this inequality in the form of (5). This is equivalent to determining q, so that 


the following equality holds: 
= _ l-a 14+7, 
(2g, — 1) w = -In( a )-m (H), 


and z; := (1 — xi) /2, so that 


where the left-hand side equals the left-hand side of (5) with w;is := In (2 


it 


Solving for q, yields (7). 
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Remark 1. Based on the findings of Theorem 1 about the optimal quota and weights, cf (7) and (8), we have the 
following remarks. 

e The optimal quota (7) depends on the validators’ profiles, and hence, it may vary between different time slots 
t > 0. Also, it may vary according to the values of the parameters «, f, and (@,. For instance, the selection 
a = 1/2 neutralizes the bias due to assumptions on the distribution of valid versus invalid blocks whereas the 
selection 7, = @, neutralizes the bias due to differences in perceived network costs/rewards. In this way, Theorem 
1 maximizes the collective welfare—or equivalently, the probability of consensus on the correct decision—by an 
easily adaptable and dynamic decision rule. 

e In blockchain applications, it may be desirable to enforce certain restrictions, as for example that the required 
weighted majority will be no less than 2/3 of the total weights or that each individual weight will be no less 
than some threshold value. As Shapley and Grofman”, p332 explains, even in such cases of additional restric- 
tions and/or perturbed assumptions, selecting weights that are proportional (or equal) to the optimal ones (8) will 
improve the probability of a correct outcome compared with unweighted decision making. 

e For any voting profile p € (0, 1), the optimal weight w = In (p/ (1 — p)) is given in Figure 1. 

For voting profiles p < 0.5, the weight is negative which motivated our selection of suspending validators 
with profiles less that 0.5. Intuitively, this means that these validators behave more than 50% of the time not as 
expected and hence have an adverse impact to the consensus mechanism. Such validators could be even replaced 
by a random coin (which would be correct 50% of the time). By properly initializing and suspending profiles 
above the 0.5 threshold, such mathematically trivial situations can be avoided. This is discussed in more detail in 
Section 6. 

e On the other hand, the optimal weights increase steeply as the voting profiles approach 1. For instance, a valida- 
tor with voting profile p, = 0.9 has an optimal weight wı ~ 2.2, whereas a validator with voting profile p) = 0.99 
has an optimal weight w2 ~ 4.6. In concrete terms, this means that a 10% improvement in the validator's voting 
profile resulted in a more than 100% improvement in the validator's optimal weight. In this way, the weighting 
mechanism disproportionally punishes even the slightest deviations from the optimal behavior and hence incen- 
tivizes validators to behave correctly as consistently as possible. This feature can be utilized to enforce the socially 
desired outcome of almost zero failures in the consensus mechanisms. 

e Finally, note that for applications, (5) can be simplified as follows. First, by dividing both sides with w;, we can 
normalize the weights to sum up to 1, ie, Wi, := wi/w; fori = 1,2, ... ,n. Second, by letting yi = (x; + 1) /2 asin 
the proof of Theorem 1, with y; = 1 if x; = 1 and y; = 0 if x; = —1, we can rewrite (5) as 


n 
yi, 2-1) = 2g, -1 
i=1 


or equivalently as 


n 


n 
2$ wi Ji E $w, 2 2q, -1. 
i=1 


i=1 


aL [hoa 


Optimal Weight w 
Oo 
j 
[i 


FIGURE1 Optimal weight w = In (p/ (1 — p)) for any possible voting profile 0 0.2 0.4 0.6 0.8 1 
p € (0,1) Voting Profile p 
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Profiles Weights Decision Profiles x, with f;(x) = 1 TABLE 2 Winning profiles under the optimal decision 
0.9 0.392 1 1 1 1 -1 -1 -1 scheme 
0.9 0.392 1 =i =] =i 1 1 
0.6 0.072 -1,1 1 1 -1,1 1 1 -1,1 
0.6 0.072 = II 1 ik r 
0.6 0.072 -1,1 -1,1 1 1 -1,1 1 1 
Si >0 >0 >0 >0 >0 >0 >0 


n 
Since Èw, , = 1, dividing both sides by 2 yields the approval condition 
i=1 


n 
Dwi wz Ie (11) 
i=1 


which is more handy than (but equivalent to) (5) and can be hence used for applications. This is done in Example 
land 2. 


Example 1 (Continued). Assume for simplicity that a = 1/2 and that 7, = a. In this case, 
the optimal rule is simple weighted majority, ie, q = 1/2, or by substituting in (5), fg(x) = 1 
if yy WiXj > 0 (dependence on t is omitted to simplify the notation). Using (8) and nor- 
malizing the weights to sum up to 1, we obtain w = (0.392, 0.392, 0.072, 0.072, 0.072). With 
these choices, the probability of approving a valid block is approximately 0.927 as shown in 
Table 2. 

The weighting has resulted in a voting rule, which approves a block if the two high-profile (0.9) validators agree 
on its validity (first column of decision profiles). The votes of the remaining validators come into play only if these 
two disagree. In this case, it suffices that a majority (two out of three) of the remaining validators approve the block 
(remaining six columns of decision profiles). The probabilities of decision profiles x, with fg (x:) = 1 sum up to 
approximately 0.927 as claimed 


0.9°+(“)09-01((>)0.6°+(5)0.6?-0.4) = 0.927. 
1 3 2 

The weights v; = (1/3, 1/3, 1/9, 1/9, 1/9) yield the same result and are in that sense equivalent to the optimal ones. 
In fact, there may be several other optimal choices. As mentioned above, if we impose additional restrictions such 
as a de facto 2/3-weighted majority, the weights given by (8) may not be optimal anymore. However, as Shapley and 
Grofman” remarks, they will still yield an improved probability compared with the unscaled case. In this example, 
a similar calculation as in Table 2 shows that the probability of reaching the 2/3-majority is 0.81 with the w; weights 
and approximately 0.85 with the v; weights. 


The ProcessSlot procedure in Algorithm 1 executes the weighted voting algorithm in each slot t. First, the validators 
and a block proposer are selected according to the underlying PoS protocol (as part of the PoSGetCommittee procedure). 
The committee can be a random sample or deterministic subset taken from the entire validator set, or it can be the val- 
idator set in its entirety. For example, in DPOS as implemented in TRON and EOS.IO, PoSGetCommittee would return 
the set of superdelegates. Next, the block proposed by the block proposer is retrieved and stored in the variable B—if no 
valid block has been proposed, then we assume that the value null is stored in B. Once the committee has been formed 
and a valid block has been proposed, we retrieve for each committee member the block that she voted for using the Col- 
lectVotes procedure. We then check in ProcessVotes whether the validators voted for B—if so, we record their vote as a 1 
and as a —1 otherwise. Next, the weighted voting procedure is applied independent of the underlying PoS protocol—if 
a sufficient number of committee members voted for the B, then it is committed and appended to the blockchain. In 
this way, it contributes towards a more efficient and fair consensus mechanism while remaining decoupled from the PoS 
selection mechanism. This results in a two-layered scheme that on the one hand improves the efficiency of the consen- 
sus mechanism of the PoS protocol and on the other hand can be implemented and reverted with minimal cost to the 
users. 


The function that determines the optimal quota is given in a general form (line 26) to account for implementations with a rule different from the one 
proposed in (7), as, eg, a constant 2/3-majority rule. 
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Algorithm 1 Weighted Voting in Committees 
1: procedure PROCESSSLOT(E, (p(i))ier) 
2 (V1, -.. , Vn) <— POSGETCOMMITTEE(t) 
3 B <+ POSPROPOSEBLOCK((1, ... , Vn), £) 
4 if B 4 null then 
5: (X, ...,X,) < COLLECTVOTES((v, ... , Vn), B) 
6 
7 
8 
9 


(vote(1), ..., vote(n)) — PROCESSVOTES(t) 
if WEIGHTEDVOTING((p(1q), ... , p(n), (vote(1), ... , vote(n))) then 
COMMITBLOCK(B) 
end if 
10: end if 
11: end procedure 
12: procedure PROCESSVOTES((Xj, ... , Xn), B) 
13: fori € {1,...,n} do 


14: if x; == B then > x; = i’s vote message 
15: vote(i) + 1 

16: else 

17: vote(i) — —1 

18: end if 

19: end for 


20: end procedure 
21: procedure WEIGHTEDVOTING((pi)ien » (vote (Ù)ien) 
22 fori € {1,...,n}do 


23: wi; — ln (pi) — ln (1 — pi) 

24: sum + sum +w;-vote(i) 

25: end for 

26: q = OPTIMALQUOTA((Wi)ien » &, Cr, Ca) 
27: return sum > 2q — 1 


28: end procedure 


4 | MWU ALGORITHM 


We now turn to one of the main challenges of implementing the voting profile scheme in the dynamic blockchain setting, 
which is the update of voting profiles after every time slot. The updating scheme may considerably vary depending on 
the desired result: eg, in Yu et al,*° a reputation system is proposed in which reputation increases according to a sigmoid 
function when nodes vote correctly and decreases sharply (to 0) after a single violation. While this approach adheres to 
intuition and comes with certain merits, practical applications may call for more flexibility in the updates. 

To develop a parametrizable scheme, we utilize the approach of Arora et al?! who generalize the standard MWU 
algorithm to a nonbinary setting in which experts’ scores are revised according to the impact of their decision on the social 
welfare. Using Table 1, the corresponding MWU algorithm for the present application is given in Table 3. 

Here, 6 > 0 is a (small) number subject to the exact protocol parametrization. Apart from the efficiency properties of 
the MWU algorithm that are well known, see previous studies”*?"° and references therein, this scheme can leverage the 
prevailing network conditions and adjust the updates accordingly. This can be realized by replacing 6 and/or 7,, la with 
sequences of updating parameters (6, frol at) o: The proposed scheme for updating validators’ voting profiles is given for 
completeness in Algorithm 2. If a new node comes online (T is the slot when it does), it runs the MWInitialize procedure 
to get the voting profiles consistent with the rest of the network. Once this has been completed, the function MWUpdate is 


TABLE3 Multiplicative weights updates Proposed Block B, 


Valid (1) Invalid (—1) 
Committee Approve pit (1+ ô) Pi — 5) 
Reject Pul- pis (1 + 8) 
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executed every slot to update the voting profiles. If a validator's profile drops below 0.5, she is removed from the set—this 
happens in line 25. Similarly, new validators may be added in each round, depending on the protocol implementation. 
This processed in line 29. The min in line 17 ensures that the voting strength of a single validator cannot go to infinity 
(after all, if p(i) approaches 1 then w; approaches oo as per line 23 in Algorithm 1). 


Algorithm 2 Validators’ Voting Profiles 
: procedure MWINITIALIZE(I, 6, lr, Ca, T) 
: I<- 
: tel 


1 
2 

3 

4 for i € I do p(i) — 0.5 

5: end for 

6 while t < T do 

7 (I, (p@)ier) — MWUPDATE(I, (p(i))ier, t, 6, Cr, Ca) 
8 tet+1 

9 end while 

10: end procedure 

11: procedure MWUPDATE(I, (p(i))icr, t, 6,07, Ca) 


12: (vi, ...; Vn) <— POSGETCOMMITTEE(t) 

13: B <— POSPROPOSEBLOCK((1j, ... , Vn), £) 

14: (X1; --- , Xn) <— COLLECTVOTES((v1, ... , Vn), B) 

15: for i € I do 

16: if v; = B then 

17: pvi) <— min {1 — e, pvi) (1 + ô)} >e=105 
18: else if x; = null then 

19: p(vi) = pv) A — ô)” 

20: else 

21: pvi) — pi) (1 — ô)“ 

22: end if 

23: end for 

24: if p(v;) < 0.5 and t > g then > g is the grace period 
25: I< I\{vj} > suspend validator i 
26: end if 

27: (Uy, ..., Uk) < GETNEWVALIDATORSINSLOT(t) 

28: fori € {1,...,k} do 

29: IIU {uj} 

30: plui) — 0.5 

31: end for 


32: return (I, (p(i))ier) 
33: end procedure 


4.1 | Tolerance of validator faulty behavior 


Before testing the weighted voting and MWU algorithms numerically in the Section 5, we study analytically the effect 
of the updating scheme on the validators’ profiles. Due to the parametric nature of the proposed algorithm, the question 
that naturally arises from the validators’ perspective is the following: what is the threshold of faulty behavior that can be 
sustained by the algorithm without harming my profile? In other words, what is the minimum percentage of time that a 
validator should strive to behave properly in order to sustain or improve their voting profile. 

To explore this question, we first introduce some notation. Let q € [0,1] denote the percentage of time—measured in 
time slots, cf Section 2—that a (tagged) validator behaves according to the protocol, ie, votes as expected by default, and 
let qı € [0, 1] denote the percentage of time that this validator does not vote on valid blocks (eg, because they accidentally 
drop offline when it is their turn to vote). Accordingly, it must be that q + qı < 1, with 1 — q — qı € [0,1] denoting the 
percentage of time that the validator votes on the approval of invalid blocks. Finally, let pọ denote the starting profile of 
the validator at the period under scrutiny and for any time frame T > 0, let pr denote the validator's profile at time T. 
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Our aim is to obtain necessary and sufficient conditions on q and qi, so that the validator will improve or sustain their 
initial voting profile, ie, pr > po, where pr depends on the validator's voting behavior via q and qı. Typically, we will 
be interested in large time periods, T > 0, that properly reflect the validator's voting behavior as expressed by q and qi. 
However, the result of Theorem 2 remains correct for any T > 0. 


Theorem 2. Consider the updating scheme in Table 3 with parameters 6, l+, a > 0 such that f, « la and 6 € (0,1), 
(typically 6 is a small number close to 0). A validator who follows the protocol q - 100% of the time and does not vote on 
valid blocks qı - 100% of the time, with q, qi € [0,1], and q + qi < 1, will improve upon their initial profile if and only if 


q2c(1-¢2q1), (12) 


In(1+6) 
f, In(1—6) 


=j 
where cı := (1 = ) and c := 1 — f, / la are positive constants that depend on the updating parameters ô, l, 


and la. 


Proof. The positivity of cı and c, follows directly from the assumptions. Indeed, 7, < la implies that ?,/?, < 1 and 
hence that c2 > 0. Similarly, 6 € (0,1) implies that In(1 — 6) < 0 and In(1 + ô) > 0 and hence that cı > 0 as the 
inverse of the sum of two positive terms (in particular, cı < 1). 

Concerning (12), let po denote the validators initial voting profile and let pr denote the validator's voting profile 
after T time slots. Then, given that q denotes the fraction of time slots in which the validator voted correctly and qı 
the fraction of time slots in which the validator did not approve a valid block, we have that 


pr=0 +AT (a-t ((1 — 8)e) "py = (a + 6) - Daalia) po. 


T 
Hence, pr > po if and only if ( (1 + (1 — EEn a(1=070)) ) > 1. Since, the basis term is positive by assumption, 


we may take the natural logarithm of both sides to obtain the equivalent condition 

qln (1 + ô) + (qi. + fa (1 -q - qı) ln (1 — 6) > 0. 
Using that (1+ 6) > 1 and some standard algebraic operations, we can solve the last inequality for q to obtain the 
necessary and sufficient condition 


1 
q z _ _nd+ô) 
la ln(1—8) 


-d-q0-2,/@,)), 


which concludes the proof. 


Remark 2 (Policy implications). The result of Theorem 2 can be utilized in the design policy of the updating algorithm 
to enforce certain requirements in the validators’ realized correct behavior, q. To see this, we first observe that cı can 


be rewritten as 1 

Bee (« Z ndra) 

1 CE ma-s) 

Since 6 is typically a small positive number, eg, 6 = 107°? and Z, is a positive number large enough to represent the 
potential losses from appending an invalid block to the blockchain, cı gets arbitrary close to but strictly less than 1 
for increasing values of f4. Moreover, for large values of fa and small values of 7,, c2 := 1—7@;/@a is also close to but 
strictly less than 1. This implies that 1 — € < cic) < 1 for some relatively small e > 0. Hence, using that q + qı < 1, we 
may rewrite (12) as 
Cy — C13 


G+ 102g 2Cg È A-ac)qtaan@g+q) 2a > -acq +a ce > qe i= 
= €1¢2 


This gives a lower bound on q that does not depend on qj. It is obvious that if the parameters 6,7,, and ĉa 
are selected in a way to push cı close to 1, then a validator will have to vote consistently correctly to retain or 
improve their voting profile. In general, this shows the advantages of the parametric approach and the flexibil- 
ity that it conveys to the policy makers or consensus designers (in case of public, permissionless blockchains) to 
enforce desired outcomes or even to dynamically adapt the consensus algorithm in response to prevailing network 
conditions. 
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5 | NUMERICAL TESTS AND PRACTICAL USE CASES 


To visualize the proposed scheme, we study some instantiations of the weighted voting and MWU algorithms. Before 
going into the details of each case, the following hold in general. 


e Adversarial model: an adversary blocks v% of the votes, either by abstaining (accidentally or intentionally) or by cen- 
soring other validators. To demonstrate the efficiency of the model in extreme—or worst case—conditions, we show 
simulations for v = 40%,50%, and 60%. For lower values of v, ie, for less adversarial power, the results are similar 
(better) and thus omitted. 

e Parameter choice:a, the prior probability that a proposed block is invalid, is set to 1/2. This choice neutralizes the 
bias due to assumptions on the distribution of valid-invalid blocks in (7) and corresponds to the most general model. 
To capture that costs from approval of invalid blocks are higher than costs from rejection of valid blocks, we select 
la = 12 > 107? = /,. The resulting graphs (recovery times) are robust in a wide range of these parameters. Yet 
very low values of fa may lead to unwanted behavior: validators who are commonly offline may still improve their 
profiles despite not voting on valid blocks. Finally, the updating parameter 6 has been chosen according to the related 
literature.”*° Different values of 6 affect the rate of convergence of the profiles. 

e Simulation environment: The numerical results have been established in MATLAB R2018b. The simulations validate 
the algorithms for resuming consensus, cf Figures 2 and 3 and for updating a validator's profile, cf Figures 4 and 5. Fur- 
ther issues related to scalability and computational complexity on a proper—or simulated—blockchain are discussed 
in Section 6. 


Figure 2 illustrates a scenario with an adversary blocking 40% of the votes. At the start of the attack, all n validatorsthave 
a voting profile p = 0.9. We examine two choices of the updating parameter 6 = 107° (red) and 6 = 2 x 10-3 (blue). In 
both cases, a = 1/2 and f, = 1077, fa = 12. 


IThe exact number does not change the results. For simplicity, we used n = 100. 
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The depicted curves indicate that the weighted approval votes (vertical axis) rise above the 2/3 majority threshold* for 
both cases. The pace is different and depends on the selection of ô. The sharp bends in both lines correspond to the point in 
which the scores of voting validators numerically reach 1. After this point, the majority of the voting validators increases 
at a very slow pace which is a desirable property that allows for a more smooth recovery in case that the abstaining 40% 
resume voting. Specifically, the exact formula for updating their profiles is 


Pits = min{1 — 107°, max{0.5, pi’, }}, 


where P!’ rr is the value calculated by Table 3. This formula ensures that p;; remains in [0.5, 1). 


Remark 3. To avoid the numerical instability at p = 1—for which the denominator at In (1/ (1 — p)) becomes equal 
to 0O—we need to restrict profiles away from 1. Specifically, to implement and test this scheme, we require that voting 
profiles do not exceed 1 — e for some very small e > 0. However, due to the steep increase of the optimal weights 
that was mentioned in Remark 1, the actual value of the imposed threshold e matters, and it should be chosen to be 
numerically close to 0. Moreover, again, due to the disproportional increase of the optimal weights for profiles close 
to 1 — e, validators who achieve this threshold (and remain at it by continuing to vote correctly after reaching it) have 
disproportionally higher power to influence the consensus outcome. 


As a comparison, Figure 3 illustrates the process of resuming approval of blocks in the same scenario but with an 
adversary controlling 50% of the stake (left panel) and 60% of the stake (right panel). The results indicate a very similar 
recovery pattern, cf Figure 2, independently of the initial stake of the nonvoting validators. The evolution of a validator's 
voting profile is illustrated in Figure 4. In the depicted scenario, the validator's initial profile is 0.9. She votes correctly 80% 
of the time, but drops 10% of the time offline, and votes on invalid blocks another 10% of the time. Again, we examine 
two cases for different values of the update parameter, 5 = 2 x 107? (left panel) and 6 = 107? (right panel). 

While the patterns differ, in both depicted panels, the voting profile falls due to the regular incorrect votes. We remark 
that lower values of 7, would result in upwards sloping curves (not depicted here) implying that a validator could regularly 
vote incorrectly and still improve her voting profile. Similarly, higher values of 6 would allow validators to quickly recover 
their profiles after pitfalls, which is an undesirable property. The depicted patterns in the evolution of the voting profile 
are robust in the choice of the initial score and the value of 7,. 

Finally, Figure 5 extends the above scenarios to a period in which the validator resumes proper voting. Specifically, we 
assume that the validator votes correctly on every block except of occasional time slots—less than 10% of the time—in 
which she goes offline. Again, the two panels correspond to different values of 6. 

In both cases, the pattern is linear (the sharp bends correspond to the occasional drops) with a slope that can be 
adjusted by the choice of 6. In sum, the simulations support the versatility of the proposed scheme and leave the exact 
parametrization (static or dynamic) subject to each protocol's implementation and scope. 


5.1 | Use case: Ethereum blockchain with Casper FFG 


To further test the proposed scheme in a potential practical scenario, we consider the implementation of weighted vot- 
ing in Ethereum's Casper FFG as a PoS overlay on top of the PoW main chain.*! This is a hybrid consensus system in 
which, roughly, PoS validators—stakers—vote to confirm (validate) blocks that have been proposed by “conventional” 


* While the optimal quota, cf (7), remains slightly above 1/2, we consider the 2/3-majority rule which is currently implemented in PoS protocols. 
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FIGURE 6 Illustration of Casper Friendly 
Finality Gadget (FFG). The boxes represent 
checkpoint blocks, and each value inside a box 
represents the fraction of validators that voted 
for that checkpoint. Thick edges around a box 
indicate that the checkpoint is finalized, dashed 
edges indicate mere justification, and a dotted 
edge a checkpoint that is neither. If a 
considerable fraction (in this case 50%) of 
validators suddenly goes offline, then 
finalization stalls. In Casper FFG, the protocol is 
eventually recovered by gradually slashing the 
deposits of offline validators. Using weighted 
voting, this can be achieved without causing 
financial losses to the validators. For more 
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PoW miners at regularly occurring checkpoints. To become a validator, a user has to deposit a chosen amount of ETH, 
Ethereum’s native cryptocurrency. If more than two-thirds of the validators (where each validator is weighted propor- 
tionally to the size of her deposit) vote to approve a given checkpoint block, then it is considered justified, and if two 
checkpoint blocks in a row are justified, then the first block is considered finalized. Ethereum nodes will never drop final- 
ized blocks during a chain reorganization, so finalization provides an additional layer of security to the users. If more than 
one-third of the validators go offline or are subjected to a network partition or eclipse attack, then checkpoints cannot be 
finalized. The system eventually recovers in the following way: after each checkpoint, those validators who did not vote 
are penalized, which means that their fraction of the total deposit decreases. Eventually, their deposit fraction will fall 
below one-third—hence, the voting validators regain a two-thirds supermajority and the ability to finalize. Of course, it 
would be harsh on the nonvoting validators if their deposits were shrunk quickly during a network partition on eclipse 
attack, which would by itself disincentivize potential validators. The penalties are therefore initially very mild, but they 
become harsher over time. This is illustrated in Figure 6. 

The main contribution of the currently proposed weighted voting scheme in Ethereum’'s Hybrid Casper Protocol setting 
is that it enables the protocol to recover without hurting the deposits of the validators. Instead, validators who come 
back online eventually regain their voting profile without any financial losses. This also allows for faster recovery during 
network partitions: although network partitions that last for more than a day are extremely rare, a quick recovery that is 
achieved by slashing the deposits of offline validators may discourage potential validators from depositing. 

The practical advantages of weighted voting are achieved without affecting either the underlying PoW blockchain or the 
PoS checkpoint finalization protocol. Instead, it operates within the selected committees and hence affects in a minimal 
way any suggested/existing scheme that is functional on the blockchain. This means that this scheme can be launched 
and reverted with minimal impact on client implementations and updates. 
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5.2 | Use case: Incentives and risk mitigation in PoS protocols 


Several current PoS proposals including Ouroboros,'**3 Casper FFG,'+“ and DPOS as implemented in EOS.IO suggest 
the following properties. 


P1: A limited number of pools or committee members, which is achieved through a minimum deposit for each potential 
validator. 
P2: A fixed period (number of protocol epochs) of time for which the staked deposit will remain locked. 


As we discuss in the following, weighted voting and updating schemes become particularly relevant under these 
conditions. Up to now, we have assumed that the PoS reward mechanism is retained, ie, that validators are rewarded pro- 
portionally to their stake. However, if there are large discrepancies between the voting profiles, validators with high voting 
profiles contribute more to the consensus than validators with lower profiles. This may raise issues about the distribution 
of staking rewards and the adopted reward scheme. 

To deal with such issues in a similar setting of decentralized multiagent decision making, Bachrach and Elkind?’ and 
Aziz and Paterson’ study incentives under the conventional reward scheme that gives to the participating agents their 
Shapley**? or Banzhaf values.*+*° In blockchain applications, the relevant question to address is whether the decision 
scheme together with the reward scheme create incentives for validators to merge, split, or annex their deposits to larger 
pools.*° Bachrach and Elkind?’ quantify the potential profit from creating various identities to participate in the weighted 
voting mechanism and show that given the number n of participating agents, a Sybil attack cannot earn to a potential 
adversary more than 2n/(n+1) ~ 2 times their initial values. Moreover, both Bachrach and Elkind? and Aziz and 
Paterson’ demonstrate that it is computational difficult, ie, NP-hard, to find such profitable manipulations (mergers or 
splitters). 

These findings are promising and suggest that reward schemes that have been developed in the context of traditional 
coalitional games can be used to incentivize proper behavior in the consensus mechanisms of blockchain protocols. By 
using properties P1 and P2 as above, we significantly mitigate the related risks. Indeed, setting a number of allowed 
validating pools (P1) together with a large enough minimum required deposit increase the difficulty for splitters. Yet taking 
these precautions to the other extreme takes its toll on decentralization and hence such measurements should be exercised 
to a limited extent. In any case, the fixed period for which deposits remain locked (P2) seems to significantly reduce the 
potential for movements in the short run at no significant trade-offs with other blockchain protocol design principles. 


5.2.1 | Eclipse attacks 


The weighted voting scheme is engineered to accelerate recovery of consensus and prevent the blockchain from stalling 
when a fraction of validators is offline or in general does not vote. Validators that continue to vote increase their voting 
profiles and hence their power to influence the consensus outcome, whereas the voting profiles of nonvoting validators 
deteriorate. Furthermore, each validator's optimal weight depends only on that validator's voting behavior (or profile) and 
hence can be computed independently of the committee in which this validator participates. However, this is not true for 
the relative power of each validator in each committee. An example is given below. 


Example 2. Consider a validator i = 1 with profile pı; = 0.99 and two different committees: 


Committee in t = 1: n = 10 validators with voting profiles, pı = (0.99, 0.7, ... ,0.7), 
Committee in t = 2: n = 10 validators with voting profiles, p2 = (0.99, 0.95, ... ,0.95). 


As in the numerical tests, we will assume that 7, = 1072, 2, = 12, and a = 1/2 for both committees. Applying (7) on 
these values yields the optimal quotas q, = 0.604 for t = 1 and q, = 0.54 for t = 2. The unnormalized optimal weight 
of validator 1 is equal to w; = In(0.99/ (1 — 0.99)) = 4.595 in both committees. However, their normalized weights 
Wi, pl=1,2, which will be used to assess the block approval condition (11), are equal to wia = 0.376 and Wi> = 0.148, 
respectively. This shows that validator 1 is better off in the first committee. 

To reach this conclusion, the second committee was selected with much worse—in terms of their voting 
profiles—validators. However, similar discrepancies in validator 1's optimal normalized weight can be observed even 


in the presence of only two equally good validators. 
Committee in t = 3: n = 10 validators with voting profiles, pı = (0.99, 0.99, 0.95, 0.7, ... , 0.7). 


In this case, the optimal quota q, is equal to q} = 0.57 and validator 1's optimal normalized weight is equal to 


13 = 0.254. Similarly, validator 2's optimal normalized weight w/ , is also equal to 0.254, and validator 3's optimal 


WwW, 
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normalized weight is equal to 0.163. This highlights the power of these three validators to decide the consensus 
outcome in committee 3. 


The previous example reveals two interesting facts. On the one hand, the dynamic adjustments in the optimal quota 
and validator's normalized weights create a consensus mechanism with intriguing properties when compared with static 
alternatives. The versatility of this algorithm under the concurrent theoretical guarantees that it optimizes the probability 
of a correct decision, or more accurately, the expected collective welfare, motivate further research both from theoretical 
and practical perspectives concerning its adoption. 

On the other hand, the dependence of the validators’ relative power on the profiles of the other committee members 
creates a incentive for malicious behavior that should be taken into account. Specifically, since validators’ relative power 
increases as the profiles of the other committee members decrease, this motivates adversarial validators to perform eclipse 
attacks and prevent other validators from voting properly. However, for such attacks to be profitable, the attackers needs 
to sustain their profile which means that they need to keep voting properly. Moreover, the actual outcome on the overall 
collective welfare will depend on the trade-off between the size of the attacker's stake and the size of the eclipsed validator's 
stake along with detection and potential penalties on such behaviors. In any case, fixing parameters as in P1 to P3 seems 
to reduce the arsenal of potential attackers but a precise verdict on whether such attacks can be profitable depends on the 
exact protocol parametrization and should be examined separately in every case of adoption. 


6 | DESIGN AND LIMITATIONS 


The introduction of validators’ voting profiles and the improvement in the consensus mechanism come with a 
trade-off in terms of security. Since the system becomes dependent on information that can be retrieved from the 
blockchain—validators' votes are stored as messages*t—this raises new risks on adversarial manipulation of this 
information. In the current section, we try to address these risks alongside implementation issues and limitations. 


6.1 | Defense against known attacks 


To defend against consensus level attacks, current PoS proposals leverage the fact that nonvoting nodes can be identified 
and penalized.'*° Yet these actions are ineffectual against adversaries who can censor other validators or replenish their 
own stake and withstand the penalties to retain more than the required consensus-quota of the total stake.!>!8 Although 
pessimistic, the scenario in which adversaries sustain an attack despite suffering losses on their own stake gains credence 
in the presence of potential out-of-protocol profits. Further, consensus mechanisms that rely on PoS selection are vulner- 
able to flash or blindsiding attacks conducted by entering nodes %58 or to accidental faults such as network latency, bad 
connectivity, or simple negligence. Weighted voting provides lines of defense (in an obvious way) against these kinds of 
attacks or faults while retaining the benefits of the underlying PoS design. In addition, the preserved reliance on PoS for 
the selection of validators in committees and the allocation of rewards protects against adversarial nodes that maintain 
small stake but high voting profile or vice versa. 


6.2 | Valid-invalid blocks 


A likely contentious assumption of the present model is that proposed blocks can be identified as valid or invalid.! In 
practice, different nodes may have different views of the blockchain and hence perceive proposed block differently. Yet, 
on closer inspection, this assumption can still be supported in the current framework: if a node is honest but has a (com- 
pletely) different view of the canonical chain due to (say) poor connection to the network, then her votes do not contribute 
to extending the canonical chain and indeed can be regarded as incorrect. For instance, in Ethereum, which is the base 
case for this paper, valid-invalid votes are well defined and identified.?°>° 


6.3 | Updating scheme and computational complexity 


Dealing with the issue of valid-invalid blocks becomes more relevant in the design of the updating scheme. Clearly, 
faults that can be identified as deliberate should be treated differently than accidental ones. For instance, a validator 
who has honestly participated in the protocol for a long period of time and drops offline for a short period of time 


| This is a chicken-egg problem: if we can identify the “canonical” blocks, then we can improve consensus with a scheme as the one proposed here. But 
in blockchains, the “canonical” blocks are precisely the ones for which consensus was reached. 
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should be able to quickly recover her previous voting profile. This motivates updating profiles by two variables s; and lj, 
representing short-term and long-term voting, respectively. In general, the advantages of the here employed generalized 
MWU algorithm—eg, convergence rates and tight bounds on its overall performance” —can be further exploited along- 
side stability properties of opinion dynamics in networks® to yield more robust results also in the present context. Finally, 
the computational complexity of initializing, storing, and updating validators’ profiles does not exceed the complexity of 
performing the same functions on validators’ stakes, and hence, it is not expected to have a significant impact on the over- 
head of any consensus that keeps track of validators’ stakes. This intuition is even more likely to materialize within the 
framework of most state of the art proposals, like EOS.IO, Casper, and Ouroboros, that promote consensus systems with 
a limited number delegates, staking pools, or potential validators. 


6.4 | Entry and threshold voting profiles 


The levels at which voting profiles are initialized and suspended are crucial, since they can incentivize or prevent Sybil 
attacks. The exact parametrization can be case-depend, justified by simulations or incorporate prior information for 
each entering validator, eg, reputable financial institution versus unknown private staker. The present choice to ini- 
tialize voting profiles at 0.5 and to require that they remain in [0.5,1) for all t > g > 0, where g denotes a potential 
initial grace period, is supported by both intuitive and theoretical arguments. From a mathematical perspective, the 
initial choice of 0.5 represents an uninformative prior on an entering's validators voting profile. Similarly, the reason 
for the upper bound is purely numerical, namely, to avoid the instability in In (pi:/ (1 — pis) ) if pix = 1. In con- 
trast, the suspension of validators with voting profile—or probability of making a correct decision—lower than 0.5 is 
more fundamental. Ben-Yashar and Nitzan?” provide a detailed probabilistic argument to explain that such voters are 
harmful to consensus, and their votes should not be considered. Moreover, in the specific context of distributed net- 
works, allowing nodes to participate with scores lower than their initial one triggers Sybil attacks, since it motivates 
switching to new or creating multiple accounts. Finally, suspending validators in terms of their voting behavior relaxes 
the need for frequent economic penalties.* This makes the PoS ecosystem more secure and appealing to investors 
who would otherwise be concerned of suffering losses due to accidental misbehavior, eg, dropping offline or being 
censored. 


6.5 | Future implementation 


Currently, the proposed scheme seems more attractive for systems with low numbers of staking nodes: these may be 
permissioned and DPOS blockchains or blockchains with fixed number of stake pools. More closely related to this 
spirit are the proposals of previous studies.'+1%382 In these settings, the computational complexity of implementing 
a profiling system is not an issue. However, this is also expected to remain true in the general case of permissionless 
blockchains, since extra data storage is limited to one additional value per validator, and computations to update pro- 
files are linear in the size of the committees. Light on this issues will be shed by future implementations on simulated 
blockchains and if successful on properly designated testnets of these blockchains. The core of these studies will be 
the understanding of issues related to network conditions (latency and scalability), computational complexity to store 
and retrieve profiles, and the testing of different updating schemes in terms of their convergence rates and efficiency 
bounds. 


7 | SUMMARY AND CONCLUSIONS 


Existing PoS protocols select staking nodes proportionally to their stake to form block-creating committees. Yet they do 
not guarantee that selected committees will create blocks, since consensus may fail due to accidental or adversarial behav- 
ior. Thus, the perceived fairness in the distribution of rewards in proportion to the stake of participating nodes is actually 
violated. Motivated by this observation, we studied weighted voting as a way to improve the consensus mechanism. We 
introduced validators’ voting profiles—that quantify the probability that a validator will cast a correct vote based on her 
so-far contribution to the protocol—and defined the proper mathematical framework to apply the results of Ben-Yashar 
and Nitzan” on optimal decision rules in committee voting. Using the approach of Arora et al, we designed a mul- 
tiplicative weights algorithm to update individual validator's profiles according to their voting behavior, the consensus 
outcome, and collective blockchain welfare. The result is a two-layered scheme in which selection of nodes and alloca- 
tion of rewards are performed by the underlying PoS mechanism, whereas blocks are decided by a weighted majority 
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voting rule. This scheme improves consensus within selected committees by scaling votes according to validators’ profiles 
without interfering with the PoS execution. Hence, it can be tested, implemented, and reverted with minimal cost to exist- 
ing users. On the negative side, the introduction of a profiling scheme in a distributed network raises new risks associated 
with manipulation of the relevant information. We discussed such risks along with actions that should be considered in 
the design of future PoS protocols. 
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